Dokploy lleva poco mas de un anio en desarrollo serio y este verano de 2025 ha alcanzado una version 0.16 que empieza a parecer madura. La propuesta es clara: dar una experiencia tipo Vercel o Render, pero sobre tu propia infraestructura y sin depender de un Kubernetes completo. La base es Docker Swarm, la interfaz es una aplicacion web que orquesta stacks, y la curva de aprendizaje es medida en horas, no en semanas. Llevo un mes probandolo en un cluster de pruebas y ya tengo opiniones.
Que es Dokploy en una frase
Dokploy es un panel de control web que se instala en un nodo Debian o Ubuntu con Docker Swarm y permite desplegar aplicaciones desde repos Git, imagenes de contenedor o archivos compose sin tocar la linea de comandos. Incluye Traefik integrado para terminacion TLS automatica con Let’s Encrypt, gestion de dominios, copias de seguridad de bases de datos, plantillas para servicios comunes como WordPress o Ghost, y una capa de colaboracion basica con equipos y permisos.
La instalacion es un script de una linea que levanta la propia aplicacion Dokploy como una pila en el mismo Swarm que gestiona. Esto tiene una propiedad interesante: Dokploy se despliega a si mismo con sus propias primitivas, de forma que las actualizaciones del panel pasan por el mismo camino que las de cualquier aplicacion que gestione. No hay una distincion entre plano de control y plano de datos en el sentido tradicional.
Donde encaja entre los competidores
El mercado de PaaS autoalojado esta bastante poblado. Coolify es el competidor mas directo, con un modelo conceptualmente similar pero con algunas diferencias clave. CapRover lleva mas anios pero tiene una comunidad mas pequenia y menos soporte para Swarm multinodo. Portainer es potente pero enfocado a operadores, no a desarrolladores. Las plataformas Kubernetes como Kubero o Ketches requieren mas inversion inicial.
La diferencia de Dokploy con Coolify es filosofica. Coolify apuesta por soportar todo: Docker, Swarm, Kubernetes, servicios externos, mil plantillas. Dokploy apuesta por hacer Swarm bien y poco mas. Esta simplicidad es a la vez fortaleza y limitacion. Si tu caso encaja en Swarm, la experiencia es mas pulida que en Coolify. Si necesitas algo fuera de ese modelo, te quedas corto.
Para equipos pequenios que no quieren operar un cluster Kubernetes pero necesitan mas que un servidor con docker compose, Dokploy ocupa un hueco real. Tres nodos Swarm, un panel web, TLS automatico, y aplicaciones que se redespliegan solas cuando hay un push a main. Eso es el 80% del valor de un Vercel autoalojado a una fraccion de la complejidad operativa.
La integracion con Traefik
Dokploy incluye Traefik como proxy inverso y lo configura automaticamente para cada aplicacion que despliegues. Cuando creas una aplicacion y le asignas un dominio, Dokploy genera las etiquetas Traefik correspondientes, solicita el certificado Let’s Encrypt y deja la aplicacion accesible por HTTPS sin mas intervencion. Esto es exactamente lo que se espera de un PaaS y funciona bien en el 95% de los casos.
El 5% restante es interesante. Si ya tienes un Traefik corriendo para otros servicios fuera de Dokploy, hay un conflicto de configuracion que no esta bien documentado. La solucion oficial es dejar que Dokploy gestione Traefik tambien, lo que obliga a migrar la configuracion existente. En mi caso, con un Traefik muy personalizado para CrowdSec y forward-auth con Authentik, esto no era aceptable. Termine configurando Dokploy en modo sin Traefik y enchufando manualmente las aplicaciones al Traefik existente mediante redes compartidas, lo que funciona pero pierde parte de la magia de la plataforma.
La experiencia de desarrollador
La parte que mas me ha gustado es la integracion con Git. Conectas un repo de GitHub, Gitea o GitLab, eliges la rama, defines si es una aplicacion Docker, Nixpacks o Buildpacks, y cada push al repo dispara un redespliegue. El historial de despliegues queda visible, con logs de construccion accesibles en el navegador y la posibilidad de revertir a una version anterior con un clic.
El soporte de Nixpacks es el que mas me sorprende positivamente. Nixpacks detecta el lenguaje y el entorno de la aplicacion sin necesidad de escribir un Dockerfile. Para una aplicacion Node.js, Python o Go, esto significa que no tienes que pensar en empaquetado. Empujas codigo, Nixpacks construye una imagen sensata y Dokploy la despliega. La imagen resultante no es la mas eficiente posible, pero para iterar en desarrollo es muy practico.
La gestion de secretos tiene margen de mejora. Los valores se almacenan cifrados en la base de datos del panel, pero no hay integracion con Vault, Infisical u otros gestores externos. Para un homelab esto es suficiente. Para un entorno corporativo donde los secretos deben rotarse, auditarse o segregarse por entorno, hay que anadir una capa externa.
Limitaciones reales que encontre
La primera limitacion es que Dokploy asume que el usuario tiene control total del cluster Swarm. No esta pensado para entornos multi-inquilino donde diferentes equipos comparten el mismo cluster con aislamiento estricto. Los permisos por usuario existen pero operan sobre la capa de aplicacion del panel, no sobre las primitivas de Swarm. Un usuario con acceso al panel tiene visibilidad de todos los stacks del cluster.
La segunda limitacion es la escala. Swarm funciona bien hasta unas decenas de nodos, pero mas alla empieza a mostrar sus costuras. Dokploy hereda esas costuras. No es una plataforma para cargas masivas con cientos de microservicios. Para esos casos Kubernetes sigue siendo la respuesta correcta, con toda su complejidad asociada.
La tercera limitacion es el estado de la documentacion. Cubre bien los casos felices y se queda corta en los casos de borde. Cuando surgen problemas de red, DNS interno, o conflictos con servicios externos, hay que ir a issues de GitHub o al Discord de la comunidad. Esto es normal en un proyecto joven, pero hay que saberlo antes de adoptarlo para algo critico.
Mi lectura
Dokploy me parece una herramienta bien enfocada para un perfil concreto: un equipo pequenio que quiere autoalojarse por razones de coste, privacidad o control, que ya conoce Docker pero no quiere aprender Kubernetes, y cuyas cargas encajan en Docker Swarm. Para ese perfil la ganancia respecto a scripts ad hoc sobre compose es clara: todo el ciclo de vida de la aplicacion esta en un sitio, el TLS se gestiona solo, y el equipo puede autoservirse sin pedir acceso SSH para cada cambio.
Para equipos que ya operan Kubernetes, Dokploy no aporta suficiente para justificar la migracion. Swarm sigue siendo menos potente que K8s en gestion de recursos, politicas de red, observabilidad y ecosistema de operadores. Si ya tienes la inversion hecha en K8s, tiene mas sentido construir encima con Argo CD o Flux que saltar a Swarm para ganar simplicidad.
El punto donde me quedo con Dokploy es en proyectos nuevos donde la incertidumbre de carga es alta y el equipo es de menos de cinco personas. En ese escenario, arrancar con Swarm y Dokploy da un tiempo de desarrollo mucho mas corto que arrancar con Kubernetes, y la migracion a K8s llegado el caso no es trivial pero tampoco imposible. El coste de oportunidad de empezar pesado por si acaso casi nunca merece la pena.
